Salesforce故障：给“我相信我的SaaS提供商......”再敲响一记丧钟

很少有服务故障像SalesForce #NA14事件这样迅速臭名远扬。但是如果全球数百万的用户依赖你的服务，那么一旦你的某个数据中心出现了故障，根本没有办法逃避得了众人的审视，更不用说服务整整停运了将近20个小时，还丢失了近4个小时的客户数据！

我敢肯定，现在我们都知道了这起事件的来龙去脉。但是万一你也在使用云服务，我们将概述一些潜在问题，这些问题催生了无数的文章、文化基因，甚至还有T恤。

先简要回顾一下，5月9日下午5点47分左右（太平洋夏令时），Salesforce的华盛顿数据中心的一部分系统出现了停电故障，结果#NA14变得无法访问。检修团队查明根源是断路器出现了故障（尽管它在2016年3月通过了负载测试）。

于是决定站点切换，故障切换到芝加哥的另一个数据中心。完成切换工作后，就在当天下午7点39分发出了“警报解除”的信号。可是没过多久，工程师们开始注意到性能下降，迅速演变为全面的服务中断。后来才发现，这归咎于存储阵列的固件错误，结果导致了写入时间显著增加，进而导致数据库开始超时――最终，一次写入操作都没有完成，导致文件不一致和数据库集群故障。

真正的问题开始出现在这里――导致数据库故障的文件不一致已复制回到华盛顿数据中心，而在同一时间，芝加哥的备用系统还没有及时完成，正因为如此，当时也无法用作恢复点。在芝加哥多次尝试恢复服务失败后，Salesforce的团队决定改而使用华盛顿的备用系统来进行恢复。遗憾的是，站点切换到芝加哥后，这并没有加以更新，所以导致5月10日凌晨2点53分至上午6点29分这个时间段输入的所有客户数据统统丢失。

没有所谓的云

许多公司对于享用云计算和SaaS模式的好处心存顾虑，而#NA14事件将这些顾虑暴露在世人面前。我们似乎太容易忘了这一点：简单来说，云就是别人的计算机。

如果我们使用云服务，实际上放弃了对我们自己的平台、服务、数据和安全的控制权，把所有这些方面的责任统统交给了出现TITSUP（完全无力支持平常性能）后，不一定收拾残局的提供商。

依赖第三方提供关键任务型服务可能有点像是一场赌博。我们期望利用SaaS平台时，有许多风险需要考虑，但是如果将适当的合同以及一套控制、政策和程序落实到位，我们应该能够管控得了这些风险。

要确保你提供商的运营灵活性和可靠性措施不仅足够到位，还要符合你自己的高标准。安全措施、备份及/或灾难恢复流程、硬件质量和部署软件更新版都有明确责任――所有这些方面都要评估潜在风险，并且以某种方式得到了保证。

许多企业组织，尤其是医疗保健、金融、保险或公共部门的那些组织面临法律要求，确保其服务提供商落实了足够有力的控制措施，保护并确保其客户数据的可用性。此外，一些国家还有地区限制，明确规定了数据可以保存在哪里或传送到哪里。

提供商本身作为一家经营性业务实体的存活性也需要考虑：财务风险、政治问题，甚至可能面临刑事诉讼的风险（尽管可能性很小），这些因素都应该考虑进来。如果你的SaaS提供商在上述任何一个方面完全失败，对方可能允许你取回自己的数据，这取决于你们签的合同协议了。但即便那样，业务仍有可能受到将这些数据倒到另一套基础设施所带来的停运影响。

这些仅仅是你选择任何一家SaaS提供商所面临的一部分潜在风险。但是这里的问题在于，让你有所思考――有时候如果不直接照管某些事情，就会忘了全面考虑底层业务运营的稳健性。有时候，我们想当然地以为，就因为提供商规模很庞大，所以我们就很安全，这种想法恐怕更要不得。

汲取的经验教训

在2008年金融危机期间，“大到不会倒”这个术语成了银行业的代名词。许多金融机构明白无误地证明了事实根本不是如此。实际上，你越大，摔得越狠。无论是企业还是消费者，我们对这些机构寄予了厚望，认为他们会以一种有利于客户利益的方式来行事和运营，而不是纯粹为了自己盈利。

现在的问题是，我们是否确保我们已汲取了经验教训，是否也在向SaaS提供商提出足够的要求？

云头条编译｜未经授权谢绝转载

相关阅读：

欢迎加入交流，群主微信：aclood